1. 大型视频网站单点分析与可用性提升
Achilles Xu
2011.03

2. 议程
 单点分类
 常规去单点方法介绍
 案例分析
 总结

3. 单点分类
 数据单点
 应用单点
 性能单点
 地域单点

4. 常规去单点方法介绍
 DNS、调度
 虚拟IP、nginx upstream、ha-proxy
 主从热备、RAID、分布式存储

5. 后台流程
用户 上传接口
转码集群 分发中心
编辑 内容平台
冷点存储
热点存储

6. 服务流程
1
用户 播放器 DNS
2
3 调度接口
存储数据库
冷热点存储

7. 上传接口
 问题：
 全国用户访问
 解决方法：
 使用动态DNS按地域分调用户
 域名再做随机哈希：upload1 … upload4

8. 内容平台
 分析：
 编辑主要集中在北京甚至公司内网
 外地编辑配置合适的代理即可

9. 转码集群
 情况和问题：
 转码设备集中在北京
 全国的上传接口都要往转码集群传送文件
 大的文件会消耗较长时间、阻塞队列
 解决办法：
 使用较好的链路（北京电信、北京网通）
 未来改成边缘转码结构，但是分发系统也要统一规划
调整
 按视频事长划分不同的队列（长视频转码队列、普通
队列、短视频转码队列）

10. 分发中心
 情况分析
 转码中心和分发中心都处在北京，彼此网络畅通，转码后的
视频文件能够瞬间传到分发中心
 抓站程序和编辑在夜间上传大量视频，无法在有限时间内（
一天）传送出去，中心出口带宽成为瓶颈
 全网都从中央抓取视频，速度太慢
 如果边缘的服务器尚未完成视频抓取，那么用户流量就全压
在中央。
 解决方法
 P2P方式，或者叫SP2SP方式，只要从中央传送出去一份，外面
的各服务器就会就近互相抓取。
 切割视频，减小单个视频大小
 升级成按块分发。
 升级使调度精确到设备。
 未来转码集群边缘化了，分发中心也不存在了。

11. 服务节点
存储1 存储2
虚拟IP
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
虚拟IP
Domain1 Domain2 Domain3 Domain4 Domain5 Domain6

12. 服务节点分析
 现状
 存储和cache的容量比大概是6:1
 每两台cache存储的内容相同
 设备占用较多，内容冗余较多
 未来措施
 考虑去除cache层
 考虑一致性哈希
 IP对外（调度精确到设备）

13. 调度系统
 现状
 调度数据库采用master/slave模式，其读库在全国有一定
分布
 调度设备的分布比读库的分布要广
 由用户访问触发，在调度设备上对部分数据做本地
cache
 本地cache以视频id计算二级hash目录，每个视频的相关信
息记录在一个文件里
 热点视频的本地cache是主动推送的
 写库是单点，不过主要是内部系统写
 措施
 未来考虑采用mysql cluster
 分表写入

14. 播放器
 一个点不可用自动尝试其他点
 该视频所有点均没有时，根据标题搜索播放相似视频

15. 审核系统
 人手不够
 机器预审
 12画面
 减少操作
 允许误杀，接投诉可快速回复

16. 评论和点击
 实时更新memcached
 memcached每5分钟写入数据库

17. 其他细节
 squid单进程浪费多核运算能力（启多实例或者把运算分到
外部进程）
 单个磁盘损坏可能会吊死所有进程（进程和磁盘绑定）
 使用容量较小的磁盘，提高并发IO能力

18. 总结
 尽量使所有系统都可横向扩展
 提前考虑系统中的大文件传输，并尽量将其边缘化
 分析所有环节、尽量减少环节
 避免重复计算（如：IP归属）
 cache

19. 谢谢！